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Description 

[0001] The present invention relates to monitoring, configuration or installation of hardware on a computer system. 

5 Discussion of the Background 

[0002] In general, computer systems include hardware and software. Hardware is the actual physical computing 
machinery, while software is the list of instructions to operate the hardware. Typically, computer systems will include a 
variety of hardware devices that interface with one another. When hardware devices interface with one another, it is 

10 necessary for the software which operates the hardware to be configured to allow communication between the hardware 
devices, so that the hardware devices can operate cooperatively. It is also desirable for hardware devices to be monitored. 
For the purposes of discussion, a hardware device that is configuring or monitoring will be referred to as a controlling 
device. Likewise, for the purposes of discussion, the hardware device that is being configured to operate cooperatively 
or being monitored by the controlling device will be referred to as an interfacing device. 

is [0003] When hardware devices initially interface with one another, it is common for the software that operates the 
devices to remain unconfigured to allow cooperative operation. Accordingly, a significant part of installing computer 
hardware devices collectively configure the software. In some arrangements, a user must configure the computer hard- 
ware manually by opening the computer hardware and physically setting jumpers or dip switches. In still some further 
arrangements, the installation process includes a user loading software from a floppy disk to configure the hardware 

20 devices. There have also been attempts for computer hardware devices to include software that can automatically 
configures hardware devices. There are, however, some apparent disadvantages and deficiencies with respect to the 
above-identified approaches. 

[0004] One disadvantage is that automatic hardware installation software is limiting in its ability to adapt to new devices 
or to new manufacturers that were not specifically programmed into the software. In the prior art, if the controlling device 
25 does not recognize the specific model of the interfacing device, automatic configuration is not possible. In other words 
if the controlling device is not programmed to anticipate the model of an interfacing device, then automatic hardware 
configuration will not be successful. In such a circumstance, a user will have to manually install the configuration com- 
munication means to the hardware devices. 

[0005] Another disadvantage of the prior art is that the controlling device is unable to partially configure hardware 
30 devices if the particular model of the interfacing device cannot be identified. In other words, if a controlling device cannot 
identify a specific model of the interfacing device, then the interfacing device will not be configured to function cooper- 
atively. This results in the unconfigured interfacing device being inoperable and essentially useless. 
[0006] It is desirable for hardware devices located on a network to be monitored for maintenance, usage, or other 
purposes. However, it has been difficult for a controlling device to communicate with various interfacing devices on a 
35 network given the different communication means between manufacturers and models of interfacing devices. These 
disadvantages prevent network administrators from obtaining crucial information about the performance and efficiency 
of interfacing devices on a network. 

[0007] DE-A1 -1 00,22,491 discloses updating a driver on a PC over the internet. 
[0008] US 5,546,595 discloses an object-oriented hardware configuration system. 
40 [0009] The present invention relates to a method of establishing a connection between at least one device and a 
monitoring system, an apparatus adapted to establish a connection to at least one device, a computer program comprising 
program code means that, when executed on a computer system, instruct the computer to perform the method and a 
system having at least one network connected device. 

[001 0] More specifically, a method and apparatus for easily creating device objects representing the monitored device 
45 is described. Initially, the controller/monitoring system attempts to establish communication with the monitored device. 
If the controller cannot be configured to interface with the monitored device, configuration information, such as manu- 
facturer, model, and a unique identifier from the monitored device are obtained. In the process of determining the 
configuration information, a determination is made to find out if the monitored device is supported by the controller using 
information from System Support Database (SSD). A device object is created using information from the SSD, thus 
50 establishing a communication protocol between the controller and the monitored device Subsequently, configuration 
information for the monitored device is updated in the System Configuration Database (SCD). 
[001 1 ] Two databases are used to configure devices with systems. These embodiments are advantageous, as valuable 
computer resources are used during the initialization of the devices with a system while preserving the computer resources 
during system operation. For example, a system may utilize two separate databases when a device is being configured. 
55 The first database (i.e. a System Configuration Database) stores device information for devices that have already been 
configured to the system and wherein operational status information of the devices is stored as the devices are being 
monitored by the system. Such device information may include the manufacturer name, and model name while operational 
status information may include the page count and toner level. 
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[0012] The device information stored in the first database is utilized during the initialization of the system while the 
status information stored in the first database is accumulated during the system operation. The first database, therefore, 
will be large since it will contain status information. Consumption of computer resources is, however, minor since the 
device information is used during initialization while status information is only added when the system is in operation. 

5 [0013] The system of the present invention also utilizes a second database (i.e. System Support Database). This 
second database may be relatively large as it would include data pertaining to a plurality of devices. When a device is 
initialized with a system, and the system is not yet configured to interface with the device, then the first database (i.e. 
System Configuration Database) can be updated using the information from the second database (i.e. System Support 
Database) so that the device can interface with the system. Due to the large amount of information stored, querying the 

w second database is not only time consuming but also uses a large amount of valuable computer resources. Once, the 
critical information (i.e. protocol) relating the device is updated in the first database with information from the second 
database, only the first database is utilized. 

[0014] In one aspect, the present invention provides a method of establishing a connection between at least one 
device and a monitoring system, said at least one device and said monitoring system being communicatively coupled 
is via a network, the monitoring system being communicatively coupled to first and second databases, the method com- 
prising the steps of: 

~(a)Uetermihing if the monitoring system is configured to interface with said at least one device; 

(b) obtaining configuration inf ormation from said at least one d evice i f the monitorin g system is not configured to 
20 interface with said at least one device; 

(c) determining if said at least one device is supported by the monitoring system using information stored in the 
second database; 

(d) creating a device object using information stored in said first and second databases to establish communication 
between said at least one device and the monitoring system, wherein the device object includes references to 

25 configuration information stored in the first database, the references using vectors or arrays; and 

(e) updating configuration information, for said at least one device, stored in the first database with configuration 
information stored in the second database to enable the monitoring system to interface with said at least one device, 
thereby allowing flexibility in the creation of device objects. 

30 [0015] The step of obtaining configuration information from said at least one device preferably includes identifying at 
least one of (i) manufacturer, (ii) model of the device, and (iii) IP address of said at least one device. The configuration 
information is only used during initialization of the monitoring system to identify said at least one device, that requires 
monitoring. The step of determining if the monitoring system is configured to interface with said at least one device 
preferably includes querying the first database with at least one of manufacturer, model, and IP address of said at least 

35 one device. 

[001 6] The step of determining if the monitoring system is configured to interface with said at least one device comprises 
querying said at least one device with data stored in the first database. The first database is a system configuration 
database which includes information for enabling communication between the monitoring system and said at least one 
device; and status information related to said at least one device, the status information being added after initialization 

40 of the monitoring system for monitoring said at least one device. The second database is a system support database 
and comprises information about various manufacturers and device models supported by the monitoring system. 
[0017] The step of determining if said at least one device is supported by the monitoring system further includes 
obtaining detailed status information of said at least one device being monitored if the manufacturer and model of said 
at least one device are supported by the monitoring system. The device object allows the monitoring system to commu- 

45 nicate with said at least one device and determine information that needs to be obtained from said at least one device. 
The at least one device object preferably stores references to information using vectors or arrays. The device object 
further stores references to information includes object identifiers. The device preferably includes hardware or software 
components. 

[0018] In another aspect of the present invention there is provided an apparatus adapted to establish a connection to 
so at least one device communicatively coupled via a network based system, the apparatus comprising: a monitoring system 
communicatively coupled to the network; first and second databases communicatively coupled to the monitoring system; 
means for determining if the monitoring system is configured to interface with the at least one device; means for obtaining 
configuration information from said at least one device if the monitoring system is not configured to interface with said 
at least one device; means for determining whether said at least one device is supported by the monitoring system using 
55 configuration information stored in the second database; means for creating a device object using configuration infor- 
mation stored in said first and second databases to establish communication between said at least one device and the 
monitoring system, wherein the device object includes references to configuration information stored in the first database, 
the references using vectors or arrays; and means for updating configuration information, for said at least one device, 
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stored in the first database with configuration information stored in the second database to enable the monitoring system 
to interface with said at least one device, thereby allowing flexibility in the creation of device objects. 
[0019] In another aspect of the present invention there is provided a computer program according to claim 24. 
[0020] In yet another aspect of the present invention there is provided a system according claim 25. 
5 [0021] An advantage of the present invention includes the ease with which to change the devices that the system 
supports by modifying the database rather than the system. 

[0022] A more complete appreciation of the present invention and many of the attendant advantages thereof will be 
readily obtained as the same becomes better understood by reference of the following detailed description when con- 
sidered in connection with the accompanying drawings. 

10 

Figure 1 is a diagram illustrating the network relationship of device 2 and system 8, in an exemplary embodiment 
of the present invention. 

[0025] Figure 2 is an exemplary flowchart illustrating the steps involved to determine if system 8 is configured to 
interface with device 2; 

15 Figure 3 is an exemplary flow chart illustrating the steps involved to determine if system 8 is configured to interface 

with device 2 using the System Configuration Database 6; 
— Figure 4is an exemplary illustration of a hierarchical approach to determine if device 2 is supported by system 8; 
Figure 5 illustrates software objects; 

Figure 6 illustrates an exemplary sequence diagram when the system is initialized to obtain.information about object 

20 identifiers used to identify the manufacturer, model, and unique identifier, and to obtain information about the man- 

ufacturers and models supported by the system; 

Figure 7 illustrates an exemplary sequence diagram for creating device objects to represent the monitored devices 
during initialization; 

Figure 8 shows the sequence diagram for executing the setAgent() 122 function of VendorModel 118; 
25 Figure 9 is an exemplary flowchart for the setAgent() function of VendorModel; 

Figure 1 0 exemplifies a sequence diagram when the system obtains information used to obtain the status information 

for the specific manufacturer and model of the monitored devices; 

Figure 1 1 shows the flowchart for the create DeviceQ function of Device Factory; 

Figure 12 shows the sequence diagram for executing the monitorStatus() function; 
30 Figure 13 shows the sequence diagram for executing the getStatus() 214 function of Device 210; 

Figure 14 shows the tables of a database having information about the manufacturers and models supported by 

the system; 

Figure 15 shows an example of the contents in the tables of the database as described in Figure 14; and 
- Figured 6 shows the class diagram for the ODBC2 package. 

35 

[0023] Figure 1 is a diagram illustrating the network relationship of device 2 and system 8. Device 2 interfaces with 
system 8 through network 4. System 8 is coupled to System Configuration Database (SCD) 6 and System Support 
Database (SSD) 1 0. Network 4 can be any type of communication structure that allows device 2 and system 8 to exchange 
data. For example, network 4 could be either a Wide Area Network (WAN), Local Area Network (LAN), or a simple cable 

40 physically connecting the device 2 and system 8. It will be appreciated that the present invention is not limiting of the 
type of networks, and that other networks may be used to enable communication between device 2 and system 8. 
[0024] System Configuration Database 6 includes information of first and second types. The first type of information 
is configuration or device information, such as, for example, manufacturer name, model name, IP address, company 
name, contact person's name, and contact person's e-mail address to name a few. The configuration information is used 

45 only during the initialization of system 8 in order to determine which devices need to be monitored. The System Config- 
uration Database 6, however, does not include information about what protocol to use to communicate with the device 
2. The SCD 6, however, includes information necessary for communication, such as for example, the IP address. 
Therefore, SCD 6 contains information that is used to determine if system 8 is configured to interface with device 2. The 
second type of information stored in SCD 6 is status information. Examples of status information include page count, 

so error status, and toner level. Status information is added to the database (SCD 6) after the initialization of the system 8 
when the system 8 is monitoring devices connected to the network 4. The System Configuration Database (SCD 6) is 
not directly dependent on the System Support Database (SSD 10). 

[0025] The S SD 1 0 includes information about manufacturers and models that are supported by the system 8. Though 
this system can support all devices irrespective of manufacturer or model, the amount of status information obtained 
55 from the device 2 depends upon manufacturers and models that are supported by the SSD 10. If the manufacturer and 
model are supported by SSD 10, then detailed status information may be obtained from the device 2. Thus, the SSD 
10 determines what type of status information is stored in the System Configuration Database (SCD 6). 
[0026] "Information from both SCD 6 and SSD 10 are used to create device objects to represent the devices being 
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monitored. Although a single device 2 is shown to be connected to the network 4, it will be appreciated that a plurality 
of devices, that need to be monitored, may be connected to network 4. The device objects allow the system 8 to 
communicate with the device 2 and determine what information to obtain from the devices. 

[0027] Figure 2 is an exemplary flowchart illustrating how it is determined if system 8 is configured to interface with 
5 device 2. In block 12, the system 8 or some other device that is part of the network 4 determines if the system 8 is 
configured to interface with device 2. For example, it is determined whether the system 8 is programmed with software 
that allows the system 8 to communicate with device 2. In other words, system 8 uses a protocol that is compatible with 
device 2, such that system 8 and device 2 can exchange data and operate cooperatively. In determining if the system 
8 is configured to interface with device 2, the system 8 also obtained configuration information from the device 2 and 
10 determines if device 2 is supported by the system 8. 

[0028] In block 14, if it is determined that system 8 is configured to interface with device 2, then in block 20, a 
communication protocol is established between system 8 and device 2, based on information stored in System Support 
Database 10. In block 22, the System Configuration Database (SCD 6) is updated with the configuration data obtained 
when determining if the system 8 was configured to interface with the device 2. However, if it is determined that the 
15 system 8 is not configured to interface with device 2 in block 14, then the process ends and device 2 will not interface 
with system 8. 

[0029] Figure 3 is an exemplary flow chart illustrating how it is determined if system 8 is configured to interface with 
device 2 using the System Configuration Database (SCD 6). In block 24, the device 2 is queried using a standard 
communication.protocol to determinejts manufacturer, model, and/or the unique identification.. . . . 

20 [0030] In block 26, if the manufacturer, model, or unique identification of the device is determined then the process 
proceeds to block 36, otherwise, the process proceeds to block 28. In block 36, it is determined that the system is 
configured to interface with the device 2. 

[0031] In block 28, the device 2 is queried using data stored in the System Configuration Database 6 to determine the 
manufacturer, model, and/or unique identification of device 2. In block 34, it is determined if the manufacturer, model, 

25 and/or unique identification of the device 2 was identified in block 28. If the determination of block 34 is positive, then it 
is determined in block 36 that the system is configured to interface with the device 2. If the determination of block 34 is 
negtive, then it is determined in block 38 that the system is not configured to interface with device 2. 
[0032] In querying the device 2 for the manufacturer and model information in blocks 24 and 28, the manufacturer 
and model of the device is checked with the System Support Database 10 to determine if the manufacturer and model 

30 is supported by the system 8. However, it does not affect whether or not the system 8 is configured to interface with the 
device 2. 

[0033] The System Support Database 10 is used to determine what status information is to be obtained from the 
device 2 when it is being monitored by the system 8. A device object for the device 2 includes information from SSD 10 
. about what status information to obtain. If the manufacturer and model, of the device is not supported in the SSD 10, 

35 then the device object will obtain status information that is available to all devices connected to the network 4. If the 
manufacturer is supported in the SSD 1 0 but the model of the device is not supported, then the device object will obtain 
status information that is available for all devices of a manufacturer. If the manufacturer and the model are supported, 
then the device object will obtain status information that is available for all devices of the model. 
[0034] Figure 4 is an illustration of a hierarchical approach to determining if device 2 is supported by system 8. In 

40 blocks 56 and 58, it is determined if the manufacturer of the device 2 is supported by the system 8. If the manufacturer 
is not supported, then in block 60 it is determined that the device is to be configured to use a generic protocol. If the 
manufacturer is supported, then the process proceeds to block 62. 

[0035] In blocks 62 and 64, it is determined if the model of device 2 is supported by the system 8. If the model is not 
supported, then it is determined in block 66 that the device 2 is to be configured using a manufacturer specific protocol. 
45 |f the model is supported, then it is determined in block 68 that the device 2 is to be configured using a model specific 
protocol. 

[0036] Figure 5 illustrates software objects. The software object Send Interface Manager 70 interfaces directly or 
indirectly with software objects DataTransfer 74, ODBC-1 72, DeviceFactory 76, VendorModel 78, ODBC-2 84, SNMP 
80, and Device 82. 
so [0037] Table 1 illustrates the functions of the ODBC-1 72. 



55 
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TABLE 1 



upaateL/OnTig 


Dciore inis Tuncuon is caneu, ine Calling Tuncuon snouiu noi itrpiaot? uie Miaiiuiauiuiei ariu niuuci 
entries if get functions return null string from VendorModel package. This function updates the device 
information database of the current record in the ODBC. This function is most efficient when the 
getConfig below is called initially. First, this function checks if IP address is same at the ODBC. If 
IP addresses are not the same, the record with correct IP address is obtained from the database. 
Then, the other fields are copied and the record is updated. 


getConfig 


This function obtains a map from ODBC for the device information in a given format. The function 
returns true if there is data returned, false if there is no more data. 


saveStatus 


This function saves the status information into the ODBC. The function returns true when saving is 
successful, false otherwise. 



15 [0038] Table 2 illustrates the functions of Device Factory 76. 

... . - - - TABLE 2 



20 



createDevice 



This function creates the device of the specification in the Device Factory. The function returns i 
pointer.to thexreated.deviceJUhexreation is successful, 0 otherwise 



[0039] Table 3 illustrates the functions of DataTransfer 74. 

TABLE 3 



25 


startSend 


This function triggers the Data Transfer to prepare for sending the data specified in the infoType. The 
function returns the EerrorCode. 




dataSend 


This function in the Data Transfer sends the received data to the appropriate destination after properly 
formatting, encrypting and encoding. The function returns the EerrorCode. 


30 


endSend 


This function in the Data Transfer ends the data sending. The function returns the EerrorCode. 



[0040] Table 4 illustrates the functions of Device 82. 

TABLE 4 



getStatus 


This function obtains status information from a device. The function returns true when the status 
is returned, false when status could not be obtained. This function resets the variable that keeps 
the error status before returning. 


checkErrorStatus 


This function triggers the device to check the error status to be saved internally. 



[0041 ] Table 5 illustrates the functions of ODBC-2 84. 

TABLE 5 



getManuflnfo 


This function obtains the name of the manufacturer, its vendor OID, the OID where the model 
information is stored, and the OID where the unique ID can be obtained. This function returns 
true when the data is returned, false when no more data is available and all the strings are 
set to null strings. 


getSupportedModel 


This function obtains the Manufacturer and supported model. There may be more than one 
instances of the same manufacturer, but the model is unique for the given manufacturer. This 
function returns true when the data is returned, false when no more data is available and all 
the strings are set to null strings. 


getManufStatuslnfo 


This function obtains the infoType and OID associated with the infoType for the given 
Manufacturer. The obtained infoType and OID pair is supported by all the devices from the 
given manufacture. This function returns true when the data is returned, false when no more 
data is available and all the strings are set to null strings. 
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Table continued 



getModelStatuslnfo 



This function obtains the infoType and OID associated with the infoType for the given 
Manufacturer and model. This function returns true when the data is returned, false when no 
more data is available and all the strings are set to null strings. 



[0042] Table 6 illustrates the functions of SNMP 80. 



TABLE 6 



setAgent 


This function sets the IP address of the device to be contacted. 


getManufacturer 


This function gets the manufacturer at the IP address. If the manufacturer is obtained, the function 
returns true. If the error is detected in the process, the function returns false. 


getModel 


This function gets the model of the device. If the model is obtained, including the null string, the 
function returns true. If the error is detected in the process, the function returns false. 


getUniqueld 


This function returns the unique ID from device. If the unique ID is obtained, including the null 
. string, -the function returns true. If the error is detected in the process, the function returns false. 



20 [0043] VendorModel 78 is responsible for obtaining information about the manufacturer and model of the monitored 
device. This software object obtains the manufacturer, model, and unique identifier of the monitored device. The class 
CVendorModel of VendorModel 78 uses information from the database to determine the manufacturers and models 
supported by the system. The class also uses information from the database needed to obtain the model and unique 
identifier from the monitored device. The public and private functions of CVendorModel are shown in Table 7 below. 

25 

TABLE 7 





Function Name 


Description 


Public 


CVendorModel () 


Constructor 




- CVendorModel () 


Destructor 




bool setAgent(std::string& in_slP) 


Creates an SNMP session for the monitored device 
and obtains the manufacturer, model, and unique 
identifier of the device 




bool getManufacturer(std::string& out 
sManufacturer) 


Returns the manufacturer of the device 




bool getModel(std::string& out sModel) 


Returns the model of the device 




bool getUniquelD(std::string & out_slD) 


Returns the unique identifier of the device 


Private 


void setVectorAndMapAttributes() 


Constructs a vector containing information needed 
to determine manufacturer, model, and unique 
identifier of the device and a map containing 
information about manufacturers and models 
supported by the system 




void obtainManufacturerQ 


Obtains information about the manufacturer from 
the device 




void obtainModel () 


Obtains information about the model from the device 




void obtainUniquelD() 


Obtains information about the unique identifier from 
the device 




void convertToAIIUpper(std::string& inOut sString) 


Converts the input string to all upper case 




std::string convertToHex(std::string& in sString) 


Converts the input string to a hexadecimal string 



55 

[0044] Table 8 below shows the attributes of the CVendorModel class that are used in the above functions. 



7 



EP 1 367 766 B1 



TABLE 8 



Type 


Attribute Name 


Description 


CSNMP 


m_SNMP 


This attribute member is used to 
implement an SNMP session for the 
monitored devices. 


std::vector<Manufactu 
rerAndModellnfo 


m_ManufacturerAndModell 
nfoVector 


This attribute member is a vector that 
contains information about the object 
identifiers used to identify the 
manufacturer, model, and unique 
identifier of the monitored devices. 


std::map<std::string, std:: 
vector<std::string » 


mJvlanufacturerModelMap 


This attribute member is a map that 
lists all the models of a given 
manufacturer in the vector that the 
system supports. 


"stcjnstring 


m_sManufacturer ~ — - 


This attribute member represents the 
Manufacturer of the monitored 
device. 






std::string 


m_sModel 


This attribute member represents the 
Model of the monitored device. 


std::string 


m_sUniquelD 


This attribute member represents the 
unique identifier of the monitored 
device. 


bool 


m_b Return 


This attribute is set to true if SNMP 
session is successful in the setAgent 
() function; false otherwise. 


std::string 


m_sCurrentModelOID 


This attribute member represents the 
object identifier used to find 
information about the model of the 
monitored device. 


std::string 


m_sCurrentUniqueOID 


This attribute member represents the 
object identifier used to find 
information about the unique ID such 
as a serial number of the monitored 
device. 



[0045] ManufacturerAndModellnfo in m_ManufacturerAnd Mode 1 1 nfoVector has the following structure: 
struct ManufacturerAndModellnfo{ 

45 

std::string m_sManufacturer; 
std::string m_sEnterpriseOID; 
so std::string m_sModelOID; 

std::string m_sllniqueOID; 

}; 

55 

[0046] m_sManufacturer is the name of the manufacturer. m_sEnterpriseOID is the enterprise object identifier asso- 
ciated with the manufacturer. The enterprise object identifier is unique to a manufacturer. m_sModelOID is the object 
identifier that can be used to find the model name of the device. m_sUniqueOID is the object identifier that can be used 
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to find the unique identifier of the device. The unique identifier can be the serial number or the MAC address of the device. 
[0047] DeviceFactory 76 is responsible for creating a device object representing the monitored device. DeviceFactory 
76 makes sure the device object knows what status information it needs to obtain. CDeviceFactory is the only class in 
DeviceFactory 76 package. The public and private functions of CDeviceFactory are shown in Table 9 below. 



TABLE 9 





Function Name 


Description 


Public 


CDeviceFactory () 


Constructor 




-CDeviceFactory () 


Destructor 




virtual CDevice * createDevice(std::string& in_slP, 
CSNMP & in.SNMP, std::string & in_ 
sManufacturer, std::string & in_sModel, std::string 
& in_st!niquelD) 


This function creates a device object representing 
the monitored device and passes into it a vector 
containing information about what status information 
to obtain. 


Private 


void setGenericDeviceVectorO 


This function sets a vector to contain information 
used to obtain status information that is obtainable 
""from all monitored devices. 




void setManufacturerVectorMap() 


This function sets a map to contain information used 
to obtain status information that is obtainable from 
all monitored devices of the specific manufacturers. 



[0048] Table 1 0 below shows the attributes of the CDeviceFactory class that are used in the above functions. 



TABLE 10 





Type 


Attribute Name 


Description 


30 


CSupportODBC 


m_SupportODBC 


This attribute member represents an 
object used to access information in the 
database that is needed to obtain status 
information of the monitored devices. 


35 


std::vector<std::pair<i infoType, std:: 
string> > 


m GenericDeviceVector 


This attribute member contains 
information used to obtain status 
information for monitored devices of all 
manufacturer and model. 


40 


std::map<std::string, std::vector<std:: 
pair<i infoType, std::string» > 


mJvlanufacturerVectorMap 


This attribute member contains 
information used to obtain status 
information for monitored devices of a 
given manufacturer. 



[0049] infoType is a number used in m_GenericDeviceVector and m_ManufacturerVectorMap used to represent a 
specific type of status information. For example, 503 represents a NoPaper condition for the monitored device and 601 
represents the page life count of the monitored device. 

[0050] Device 82 represents a monitored device. It accesses status information of the monitored device. Status infor- 
mation includes information such as error status, page count, toner cartridge level, and alerts. CDevice is the only class 
in Device 82 package. The public functions of CDevice are shown in Table 1 1 below. 



TABLE 11 





Function Name 


Description 


Public 


CDevice (std::string& in_slPaddress, CSNMP& in_ 
SNMP, std::string& in_sManufacturer, std::string& 
in_sModel, std::string& in sUniquelD) 


Constructor 




- CDevice () 


Destructor 
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Table continued 





Function Name 


Description 




bool getStatus(std::map<infoType, std::string> & 
out Statuslnformation) 


This function obtains the status information of the 
monitored device 




bool checkErrorStatus() 


This function gets the error status of the monitored 
device 




bool setNumOIDVector (std::vector<std:: 
pair<infoType, std::string> > & inj/ector) 


This function sets the vector that will be used to obtain 
the status information from the monitored device via 
SNMP. 



[0051 ] Table 1 2 below shows the attributes of the CDevice class that are used in the above functions. 



TABLE 12 



Type 


Attribute Name 


Description 


std::string - - 


m^slPAddress 


This attribute member is the IP address of the 
monitore_d device 


CSNMP & 


m_SNMP 


This attribute member is used to implement an 
SNMP session for the monitored devices. 


std::string 


m_s Manufacturer 


This attribute member is the manufacturer of the 
monitored device. 


std::string 


m_sModel 


This attribute member is the model of the 
monitored device. 


std::string 


m_sUniquelD 


This attribute member is the unique ID for the 
monitored device. 


char 


m_cError 


This attribute member is to keep the error bits 
representing the error status of the monitored 
device 


std::vector<std::pair<i nfoType, std::string> 


m_NumOIDVector 


This vector stores information that will be used 
to obtain the status information from the 
monitored device via SNMP. 



[0052] Figure 6 illustrates an exemplary sequence diagram when the system is initialized to obtain information about 
the object identifiers used to identify the manufacturer, model, and unique identifier and to obtain information about the 
manufacturers and models supported by the system . VendorModel 86 interacts with ODBC2 88 to obtain this information. 
ODBC2 88 provides an interface to the database to obtain information requested of it by VendorModel 86. VendorModel 
86 calls the function getManuflnfo() 90 of ODBC2 88 to obtain the object identifiers used to identify the manufacturer, 
model, and unique identifier of the monitored devices from the database. This information is stored in the vector m_ 
ManufacturerAndModellnfoVector described in Table 8 above. getManuflnfo() 90 is called multiple times until all the 
object identifiers for all manufacturers supported by the system are read in from the database. Then VendorModel 86 
calls the function getSupportedModelQ 92 of ODBC2 88 to obtain the manufacturer and model supported by the system 
from the database. This information is stored in the map m_ManufacturerModelMap described in Table 8 above, get- 
SupportedModel() is called multiple times until all the models supported by the system are read in from the database. 
To remove, modify, or add the manufacturers and models supported by the system, the only change necessary is in the 
database which stores information about the supported manufacturers and models. No change needs to be done to the 
system when the manufacturers and models supported by the system changes. The information is read in from the 
database during initialization. 

[0053] Figure 7 illustrates an exemplary sequence diagram for creating device objects to represent the monitored 
devices during initialization. Initially, the system 8 (Fig. 1) attempts to establish communication with device 2. If the 
system 8 cannot be configured to interface with device 2, configuration information, such as manufacturer, model, and 
a unique identifier from device 2 is obtained. In the process of determining the configuration information, a determination 
is made to find out if the device 2 is supported by the system 8 using information from System Support Database (SSD 
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1 0). A device object is created using information from the SSD 1 0, thus establishing a communication protocol between 
the system 8 and the device 2 - irrespective of whether or not the device is supported by the system 8. Subsequently, 
configuration information for the device 2 is updated in the System Configuration Database (SCD 6). SendlnterfaceM- 
anager 94 calls getConfig() 102 of ODBC 96. ODBC 96 provides an interface to the database to obtain configuration 
5 information of the monitored devices. The configuration information includes manufacturer name, model name, and IP 
address of the monitored device, the name, phone number, and email address of the contact person who is responsible 
for the monitored device. The database contains the configuration information of all devices that are to be monitored. 
However, not all of the devices in this database may be supported by the system as specified in the database associated 
with ODBC2 84 of Figure 5. 

10 [0054] SendlnterfaceManager 94 calls setAgent() 1 04, creating an SNMP session with the monitored device to obtain 
the manufacturer, model, and unique identifier of the device. More details of this function are provided in Figure 8. 
SendlnterfaceManager 94 calls getManufacturer() 106, getModel() 108, and getUniquelD() 1 10 of VendorModel 98 to 
get the manufacturer name, model name, and unique identifier of the monitored device. SendlnterfaceManager 94 calls 
createDevice() 1 12 of DeviceFactory 100 to create a device object for the monitored device. The device object will be 

15 used by SendlnterfaceManager 94 to obtain status information of the monitored device. SendlnterfaceManager 94 calls 
updateConfigO of ODBC 96 to update the configuration information in the database. 

[0055] All the steps in the sequence are repeated until all the monitored devices in the database are obtained. A device 
object will be created for each of the monitored devices. Send Interf aceManager 94 will maintain each of the device objects. 
[0056] Fig ure 8 shows the sequence diagram for executing the setAgentQ 122 function Qf_VendorMpdel 1 1 8. Send- 

20 InterfaceManager 1 1 6 calls setAgent() 1 22 of VendorModel 1 1 8. VendorModel 1 1 8 calls setAgent() 1 24 of SNMP 1 20. 
This function sets up an SNMP session between the system and the monitored device. VendorModel 1 1 8 calls its own 
function obtainManufacturer() 126 to obtain the manufacturer name of the monitored device. In the function obtainMan- 
ufacturer() 126, VendorModel 118 calls getNextStringValueForO!D() 128 of SNMP 120 to obtain the enterprise object 
identifier via SNMP from the monitored device. The enterprise object identifier is used to identify the manufacturer of 

25 the monitored device. VendorModel 118 calls its own function obtainModel() 130 to obtain the model name of the 
monitored device. In the function obtainModel() 130, VendorModel 1 18 calls getNextStringValueForOID() 132 of SNMP 
1 20 to obtain the model name of the monitored device via SNMP. VendorModel 1 1 8 calls its own function obtainUniquelD 
() 134 to obtain the unique identifier of the monitored device. In the function obtainUniquelD() 134, VendorModel 118 
calls getNextStringValueForOIDQ 136 of SNMP 120 to obtain the unique identifier of the monitored device via SNMP. 

30 [0057] Figure 9 is an exemplary flowchart for the setAgent() function of VendorModel. In step 140 the variables 
representing the manufacturer name, model name, and unique identifier are set to an empty string. These variables are 
m_sManufacturer, m_sModel, and m_sUniquelD as exemplified in Table 8. In step 142 the enterprise object identifier 
of the monitored device is obtained via SNMP. In step 144 the enterprise object identifier obtained from the monitored 
device is compared to those supported by the system. The enterprise object identifier and its corresponding manufacturer 

35 supported by the system are stored in the vector m_ManufacturerAndModellnfoVector as described in Table 8. The 
vector is searched to determine if the enterprise object identifier of the monitored device is found. If the enterprise object 
identifier cannot be found in the vector, then step 156 will be processed next. If the enterprise object identifier is found 
in the vector, then the manufacturer of the monitored device is supported by the system and step 146 is processed next. 
In step 146 the variable for the manufacturer name m_sManufacturer is set to the manufacturer name corresponding to 

40 the enterprise object identifier in the vector. In step 1 48 the variables m_sCurrentModelOID and m_sCurrentUniqueOID 
for the object identifier used to find the model name and the unique identifier of the monitored device is set to the object 
identifiers corresponding to the enterprise object identifier in the vector. In step 1 50 the model name is obtained from 
the monitored device via SNMP using the object identifier m_sCurrentMode!OID. 

[0058] In step 1 52 the model name obtained from the monitored device is compared to those supported by the system. 

45 The manufacturer and model supported by the system are stored in the map m_ManufacturerModelMap as described 
in Table 8. The map is searched to determine if the model is found in the map. If the model cannot be found in the map, 
then step 156 will be processed next. If the model can be found in the map, then the model of the monitored device is 
supported by the system and step 154 is processed next. In step 154 the variable for the model name m_sModel is set 
to the model name obtained from the monitored device. In step 1 56 the unique identifier is obtained from the monitored 

so device via SNMP using the object identifier m_sCurrentUniqueOID. Then set the variable for the unique identifier m_ 
sUniquelD to the unique identifier obtained from the monitored device. 

[0059] The functions setAgent() of VendorModel allows the system to obtain the manufacturer name and model name 
of the monitored device via SNMP to determine if it is supported by the system. Also, it allows the system to verify the 
manufacturer name and model name. 
55 [0060] Figure 10 exemplifies a sequence diagram when the system obtains information used to obtain the status 
information for the specific manufacturer and model of the monitored devices. DeviceFactory 1 60 interacts with ODBC2 
162 to obtain this information. ODBC2 162 provides an interface to the database to obtain information requested of it 
by DeviceFactory 1 60. DeviceFactory 1 60 calls the function getManufStatuslnfoQ 1 64 of ODBC2 1 62 to obtain information 
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needed to obtain the status information from monitored devices for a specific manufacturer via SNMP. The information 
includes a number (infoType) representing some type of status information and an object identifier used to obtain the 
status information via SNMP. getManufStatuslnfo() 166 is called multiple times until the information needed to obtain 
all the status information for a specific manufacturer are read in from the database. Then DeviceFactory 160 calls the 

5 function getModelStatuslnfoQ 1 68 of ODBC2 1 62 to obtain information needed to obtain status information from monitored 
devices for a specific model via SNMP. The information includes a number (infoType) representing some type of status 
information and an object identifier used to obtain the status information via SNMP. getModelStatuslnfoQ 170 is called 
multiple times until the information needed to obtain all the status information for a specific model are read in from the 
database. This sequence is called within the createDevice() function of DeviceFactory when a device object is created 

10 for the monitored device. This information will be added to the device object as described in Figure 1 1 . 

[0061 ] By using the database to store information used to obtain the status information pertaining to the manufacturer 
and the status information pertaining to the model, status information to be obtained from the monitored devices can be 
easily modify, remove, or add to the database without any changes to the system. 

[0062] Figure 1 1 shows the flowchart for the createDevice() function of DeviceFactory. In step 174 a device object is 
is created to represent the monitored devices. In step 1 76 a vector containing information needed to obtain status information 
from devices of all manufacturers is assigned to a local vector. This vector corresponds to m_GenericDeviceVector 
described in Table 10. In step 178 the manufacturer name of the monitored device is checked to see if it is supported 
by the system (the manufacturer name is an empty ^string if it is not supportelfby thesystenri)7lf"the~manufacturer name 
is not supported, then step 186 will be processed next, if the manufacturer name is supported, then step 180 will be 
20 processed next. 

[0063] In step 1 80 information needed to obtain status information from the monitored device of a specific manufacturer 
is obtained from a map and added to the local vector. The map corresponds to mJvlanufacturerVectorMap described 
in Table 10. In step 182 the model name of the monitored device is checked to see if it is supported by the system (the 
model name is an empty string if it is not supported by the system). If the model name is not supported, then step 186 

25 will be processed next. If the model name is supported, then step 184 will be processed next. 

[0064] In step 184 information needed to obtain status information from the monitored device of a specific model is 
obtained from the database and added to the local vector. In step 1 86 the local vector containing the information needed 
to obtain all the status information of the monitored device is set in the device object. The device object will have 
information about what status information it must get from the monitored device. 

30 [0065] DeviceFactory creates and initializes ail the device objects so that it knows what status information it must obtain. 
[0066] Figure 1 2 shows the sequence diagram for executing the monitorStatus() function. The process sends the 
status information of the monitored devices to a desired location. SendlnterfaceManager 190 calls startSend() 198 of 
DataTransfer 196 to prepare the system to send the status information of the monitored devices via email (SMTP). 
SendlnterfaceManager 190 calls getStatus() 200 of Device 194 to obtain the status information of the monitored device. 

35 Device 194 corresponds to the monitored device and it knows what status information it must obtain SendlnterfaceMa- 
nager 1 90 calls saveStatusO 202 of ODBC 1 92 to store the status information of the monitored device in the database. 
SendlnterfaceManager 190 calls dataSend() 204 of DataTransfer 196 to send the status information of the monitored 
device via email (SMTP). The steps of calling getStatus() 200, saveStatusO 202, and dataSend() 204 are repeated for 
each monitored device. There is a device object for each monitored device. SendlnterfaceManager 190 calls endSend 

40 () 206 of DataTransfer 196 to complete the sending of the status information via email. 

[0067] Figure 13 shows the sequence diagram for executing the getStatus() 214 function of Device 210. Sendlnter- 
faceManager 208 calls getStatus() 214 of Device 210 to obtain the status information of the monitored device. Device 
210 represents a monitored device of a specific manufacturer and model. The status information will be obtained from 
the monitored devices via SNMP. If the monitored device is not supported by the system, then the status information 

45 obtained from the monitored device is the status information obtainable for all monitored devices (all-system status 
information) such as error status. If the manufacturer but not the model of the monitored device is supported by the 
system, then the status information obtained from the monitored device is the all-system status information and the 
status information obtainable for all monitored devices of the specific manufacturer (manufacturer-specific status infor- 
mation). If the manufacturer and model of the monitored device is supported by the system, then the status information 

50 obtained from the monitored device is the all-system status information, the manufacturer-specific status information, 
and the status information obtainable for ail monitored devices of the specific model (model-specific status information). 
Device 210 contains a vector so that it knows which information it needs to obtain. Device 210 calls getNextStringVal- 
ueForOID() of Snmp 212 so the system can obtain the status information from the monitored device via SNMP. get- 
NextStringValueForOID() 218 is called multiple times to obtain all the status information from the monitored device. 

55 [0068] Figure 14 shows the tables of a database that contains information about the manufacturers and models 
supported by the system. The table also includes information about what information is to be obtained for each manu- 
facturer and model. Manufacturer 230 is the table that contains information about the manufacturers supported by the 
system. Manufacturer 230 also contains the following information- enterprise object identifier for the manufacturer, object 
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identifier used to find the model name of the monitored device, and object identifier used to find the unique identifier of 
the monitored device. SupportedModelByManufacturer 220 is the table that contains the models with its corresponding 
manufacturer that are supported by the system. To add or remove manufacturers and models supported by the system, 
only the tables Manufacturer 230 and SupportedModelByManufacturer 220 need to be modified. No modification needs 
to be made to the code of the system. The system will read the information from these tables of the database. 
[0069] ComManufStatus 226 is the table that contains information about what information will be obtained from the 
monitored device based on its manufacturer name. The table contains the manufacturer name and a number representing 
the type of information. ModelStatus 222 is the table that contains information about what information will be obtained 
from the monitored device based on its model name. The table contains the manufacturer name, the model name, and 
a number representing the type of information. To add or remove information to obtained from the monitored device, 
only the tables ComManufStatus 226 and ModelStatus 222 need to be modified. No modification needs to be made to 
the code of the system. The system will read the information from these tables of the database. 
[0070] EnumOID 224 is the table that contains information about the object identifier used to find the information 
corresponding to the number. The object identifier will be used by the system to find a specific type of information from 
the monitored device via SNMP. EnumCorrespondence 228 is the table that contains a description of the numbers used 
to represent a type of information. This table is not used by the system but will provide the user of the system information 
about what the numbers represent. 

[0071] Figure 1 5 shows an example of the contents in the tables of the database as described in Figure 14. Microsoft 
_ Access is the database used to. store .information about the manufacturers and models supported by the system. 
[0072] Figure 16 shows the class diagram for the ODBC2 package. The CSupportODBC 232 class is the interface 
for this package to access information in the database. The CManufacturerData 240 class accesses information from 
the database needed to obtain the manufacturer, model, and unique ID of the monitored device. The CSupportedMod- 
elData 234 class accesses information from the database about the manufacturer and model of monitored device 
supported by the system. The CComManufStatusData 236 class accesses information from the database needed to 
obtain manufacturer status information associated with the monitored device. The CModelStatusData 238 class accesses 
information from the database needed to obtain model status information associated with the monitored device. The 
CManufacturerDatabase 242 class provides an interface to the table in the database that contains the manufacturer 
information. The CSupportedModelDatabase 244 class provides an interface to the table in the database that contains 
information about supported models. The CComManuStatusDatabase 246 class provides an interface to the table in 
the database that contains the manufacturer status information. The CModelStatusDatabase 250 class provides an 
interface to the table in the database that contains the model status information. The ClnfoTypeOIDDatabase 248 class 
provides an interface to the table in the database that contains the correspondence between the infoType enumeration 
and the object identifier. 

[0073] CManufacturerDatabase 242, CSupportedModelDatabase 244, CComManufStatusDatabase 246, CModel- 
StatusDatabase 250, and ClnfoTypeOIDDatabase 248 are all classes derived from CRecordset 252 of the Microsoft 
Foundation Class (MFC) library. 

[0074] The foregoing description of the preferred embodiment of the present invention has been presented for purposes 
of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. 
For example, any one or more of the concepts described or shown herein may be applied to the system and/or method 
disclosed in US Patent Application Publication No. 20020152292 (Serial No. 09/756,120), filed January 9, 2001 , entitled 
"Method and System of Remote Support of Device Using Email." Moreover, any concept or feature described in US 
Patent Application No. 09/756,1 20 may be applied to the systems or methods disclosed herein. The embodiments were 
chosen and described to best explain the principles of the invention and its practical applications thereby enable others 
skilled in the art to utilize the invention. It is intended that the scope of the present invention be defined only by the claims 
appended hereto. 



Claims 

1. A method of establishing a connection between at least one device and a monitoring system (8), said at least one 
device (2) and said monitoring system (8) being communicatively coupled via a network (4), the monitoring system 
(8) being communicatively coupled to first (6) and second (10) databases, the method comprising the steps of: 

a) determining if the monitoring system (8) is configured to interface with said at least one device (2); 

b) obtaining configuration information from said at least one device (2) if the monitoring system (8) is not 
configured to interface with said at least one device (2); 

c) determining if said at least one device (2) is supported by the monitoring system (8) using information stored 
in the second (10) database; 
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d) creating a device object using information stored in said first (6) and second (10) databases to establish 
communication between said at least one device (2) and the monitoring system (8), wherein the device object 
includes references to configuration information stored in the first database (6), the references using vectors 
or arrays; and 

5 e) updating configuration information, for said at least one device (2), stored in the first database (6) with 

configuration information stored in the second database (10) to enable the monitoring system (8) to interface 
with said at least one device (2), thereby allowing flexibility in the creation of device objects. 

2. The method of claim 1 , wherein the step of obtaining configuration information from said at least one device (2) 
10 includes identifying at least one of: i) manufacturer of the device (2), ii) model of the device (2), and iii) unique 

identifier of said at least one device (2). 

3. The method as in claim 2, wherein the configuration information is only used during initialization of the monitoring 
system to identify if at least one device (2) requires monitoring. 

15 

4. The method of claim 1 , 2 or 3, wherein the step of determining if the monitoring system (8) is configured to interface 
with said at least one device (2) includes querying the first database (6) with at least one of manufacturer, model, 
and unique identifier of said at least one device (2). 

20 5. The method of claim 1 , 2, 3 or 4, wherein the step of determining if the monitoring system (8) is configured to interface 
with said at least one device (2) comprises querying said at least one device (2) with data stored in the first database 
(6). 

6. The method as in claim 5, wherein the first database (6) is a system configuration database and comprises: 

25 

configuration information for enabling communication between the monitoring system and said at least one 
device (2); and 

status information related to said at least one device (2), the status information being added after initialization 
of the monitoring system (8) for monitoring said at least one device (2). 

30 

7. The method as in any one of the preceding claims, wherein the second database (1 0) is a system support database 
and comprises information about various manufacturers and device models supported by the monitoring system (8). 

- 8. The method as in any one of the preceding claims, wherein the step of determining if said at least one device is 
35 supported by the monitoring system (8) further comprises obtaining detailed status information of said at least one 

device (2) being monitored if the manufacturer and model of said at least one device (2) are supported by the 
monitoring system (8). 

9. The method as in any one of the preceding claims, wherein the device object allows the monitoring system (8) to 
40 communicate with said at least one device (2) and determine configuration information needed from said at least 

one device (2). 

10. The method as in any one of the preceding claims, wherein the device object storing references to configuration 
information includes object identifiers. 

45 

1 1 . The method of any one of the preceding claims, wherein said at least one device (2) includes hardware components. 

12. The method of any one of the preceding claims, wherein said at least one device (2) includes software components. 

so 13. An apparatus adapted to establish a connection to at least one device (2) communicatively coupled via a network 
based system, the apparatus comprising: 

a monitoring system (8) communicatively coupled to the network; 
first (6) and second (10) databases communicatively coupled to the monitoring system (8); 
55 means for determining if the monitoring system is configured to interface with the at least one device (2); 

means for obtaining configuration information from said at least one device (2) if the monitoring system (8) is 
not configured to interface with said at least one device; 

-means for determining whether said at least one device (2) is supported by the monitoring system (8) using 



14 



EP 1 367 766 B1 



configuration information stored in the second database (10); 

means for creating a device object using configuration information stored in said first (6) and second (10) 
databases to establish communication between said at least one device (2) and the monitoring system (8), 
wherein the device object includes references to configuration information stored in the first database (6), the 
5 references using vectors or arrays; and 

means for updating configuration information, for said at least one device (2), stored in the first database (6) 
with configuration information stored in the second database (10) to enable the monitoring system to interface 
with said at least one device, thereby allowing flexibility in the creation of device objects. 

10 14. The apparatus as in claim 13, wherein configuration information includes information related to: i) manufacturer, ii) 
model, and iii) unique identifier of said at least one device (2). 

1 5. The apparatus as in claim 1 4, wherein the configuration information is only used during initialization of the monitoring 
system (8) to identify at least one device (2) that requires monitoring. 

15 

16. The apparatus as in claim 13, 14 or 15, further comprising: 

_ meanslof querying the first database (6) with at least one of manufacturer, model, and unique identifier of said 

. at least.one device (2) to determine if the monitoring system.(8) is configured to interface with said at least one 

20 device (2). 

17. The apparatus as in claim 13, 14, 15 or 16, further comprising: 

means for querying said at least one device (2) with data stored in the first database (6) to determine if the 
25 monitoring system (8) is configured to interface with said at least one device (2). 

1 8. The apparatus of any one of claims 1 3 to 1 7, wherein the first database (6) is a system configuration database and 
comprises: 

30 configuration information for enabling communication between the monitoring system and said at least one 

device (2); and 

status information related to said at least one device (2), the status information being added after initialization 
of the monitoring system for monitoring said at least one device (2). 



35 19. The apparatus of any one of claims 13 to 18, wherein the second database (10) is a system support database and 
comprises information about various manufacturers and device models supported by the monitoring system (8). 

20. The apparatus of any one of claims 13 to 19, wherein the device object allows the monitoring system (8) to com- 
municate with said at least one device (2) and determine configuration information needed from said at least one 

40 device (2). 

21 . The apparatus of any one of claims 1 3 to 20, wherein the device object storing references to configuration information 
includes object identifiers. 

45 22. The apparatus as in any one of claims 1 3 to 20, wherein said at least one device (2) includes hardware components. 

23. The apparatus as in any one of claims 13 to 22, wherein said at least one device (2) includes software components. 

24. A computer program comprising program code means that, when executed on a computer system, instruct the 
so computer system to perform the method of any one of claims 1 to 12. 

25. A system having at least one network (4) connected device (2), the system comprising: 

a controller (8) for monitoring the at least one network connected device, said controller having logic for: 

55 

determining if the controller (8) is configured to interface with said at least one network connected device (2); 
obtaining configuration information from said at least one network connected device (2) if the controller (8) 
is not configured to interface with said at least one network connected device (2); 
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first (6)and second (10) databases communicatively coupled to the controller (8), said second database 
(10) storing configuration information for determining if said at least one network connected device (2) is 
supported by the controller (8), said first (6) and second (10) databases having configuration information 
for creating a device object to establish communication between said at least one network connected device 
5 (2) and the controller (8), wherein the device object includes references to configuration information stored 

in the first database, the references using vectors or arrays; and 

wherein configuration information in said first database (6) is updated with configuration information stored 
in the second database (1 0) for enabling the controller to interface with said at least one network connected 
device (2), thereby allowing flexibility in the creation of device objects. 

10 

Revendications 

1. Procede d'etablissement d'une connexion entre au moins un dispositif et un systeme de surveillance (8), ledit au 
is moins un dispositif (2) et ledit systeme de surveillance (8) etant couples de facon communicative via un reseau (4), 

le systeme de surveillance (8) etant couple de facon communicative a des premiere (6) et seconde (10.) bases de 
donnees; le procede comprenant les etapes de : ~ 



a) determination de si le systeme de surveillance (8) est configure pour s'interfacer avec ledit au moins un 
20 dispositif (2) ; 

b) obtention d'informations de configuration a partir dudit au moins un dispositif (2) si le systeme de surveillance 
(8) n'est pas configure* pour s'interfacer avec ledit au moins un dispositif (2) ; 

c) determination de si ledit au moins un dispositif (2) est supporte par le systeme de surveillance (8) utilisant 
des informations stockees dans la seconde base de donnees (10) ; 

25 d) creation d'un objet de dispositif utilisant des informations stackers dans lesdites premiere (6) et seconde 

(10) bases de donnees pour etablir une communication entre ledit au moins un dispositif (2) et le systeme de 
surveillance (8), dans lequel I'objet de dispositif comprend des references a des informations de configuration 
stackers dans ladite premiere base de donnees (6), les references utilisant des vecteurs ou des r6seaux ; 
e) mise a jour d'informations de configuration, pour ledit au moins un dispositif (2), stockees dans la premiere 

30 base de donnees (6) avec des informations de configuration stackers dans ladite seconde base de donnees 

(10) pour permettre au systeme de surveillance (8) de s'interfacer avec ledit au moins un dispositif (2), permettant 
ainsi une souplesse dans la creation des objets de dispositif. 

2- -Proc§d6 selon la revendication 1 , dans lequel I'etape d'obtention des informations de configuration a partir dudit au 
35 moins un dispositif (2) comprend I'identification d'au moins un de : i) fabricant de dispositif (2), ii) modele du dispositif 

(2), et iii) identifieur unique dudit au moins un dispositif (2). 

3. Procede selon la revendication 2, dans lequel les informations de configuration sont seulement utilises pendant 
initialisation du systeme de surveillance pour identifier si au moins un dispositif (2) necessite la surveillance. 

40 

4. Procede selon la revendication 1 , 2 ou 3, dans lequel I'etape de determination de si le systeme de surveillance (8) 
est configure pour s'interfacer avec ledit au moins un dispositif (2) comprend Tinterrogation de la premiere base de 
donnees (6) avec au moins un du fabricant, du modele, et de I'identifieur unique dudit au moins un dispositif (2). 

45 5. Procede selon la revendication 1 , 2, 3 ou 4, dans lequel I'etape de determination de si le systeme de surveillance 
(8) est configure pour s'interfacer avec ledit au moins un dispositif (2) comprend Tinterrogation dudit au moins un 
dispositif (2) avec des donnees stock6es dans la premiere base de donnees (6). 

6. Procede selon la revendication 5, dans lequel la premiere base de donnees (6) est une base de donnees de 
so configuration de systeme et comprend : 

des informations de configuration pour permettre une communication entre le systeme de surveillance et ledit 
au moins un dispositif (2) ; et 

des informations d'etat liees audit au moins un dispositif (2), les informations d'etat etant ajoutees apres I'ini- 
55 tialisation du systeme de surveillance (8) pour surveiller ledit au moins un dispositif (2). 

7. Procede selon Tune quelconque des revendications precedentes, dans lequel la seconde base de donnees (10) 
est'une base de donnees de support de systeme et comprend des informations concernant divers fabricants et 



16 



EP 1 367 766 B1 



modules de dispositif supports par le systeme de surveillance (8). 

8. Procede selon Tune quelconque des revendications precedentes, dans lequel I'etape de determination de si ledit 
au moins un dispositif est supports par le systeme de surveillance (8) comprend en outre I'obtention des informations 

5 d'etat detainees dudit au moins un dispositif (2) etant surveilie si le fabricant et le modele dudit au moins un dispositif 

(2) sont supports par le systeme de surveillance (8). 

9. Procede selon Tune quelconque des revendications precedentes, dans lequel I'objet de dispositif permet au systeme 
de surveillance (8) de communiquer avec ledit au moins un dispositif (2) et de determiner des informations de 

10 configuration necessaires k partir dudit au moins un dispositif (2). 

10. Procede selon Tune quelconque des revendications pr6c6dentes, dans lequel I'objet de dispositif stockant des 
references & des informations de configuration comprend des identifieurs d'objet. 

15 11. Procede selon Tune quelconque des revendications precedentes, dans lequel ledit au moins un dispositif (2) com- 
prend des composants materiels. 

12. ""Pr6c6de selonTune quelconqulTdes revendications precedentes, dans lequel ledit au moins un dispositif (2) com- 

prend. des,composants Jog iciels ... __. 

20 

13. Appareil adapts pour etablir une connexion & au moins un dispositif (2) couple* de facon communicative via un 
systeme de base de reseau, I'appareil comprenant : 

un systeme de surveillance (8) couple de facon communicative au reseau ; 
25 des premiere (6) et seconde (10) bases de donnees couples de facon communicative au systeme de sur- 

veillance (8) ; 

un moyen pour determiner si le systeme de surveillance est configure pour s'interfacer avec ledit au moins un 
dispositif (2) ; 

un moyen pour obtenir des informations de configuration & partir dudit au moins un dispositif (2) si le systeme 
30 de surveillance (8) n'est pas configure pour s'interfacer avec ledit au moins un dispositif ; 

un moyen pour determiner si ledit au moins un dispositif (2) est supporte par le systeme de surveillance (8) 

utilisant des informations de configuration stockees dans la seconde base de donn6es (10) ; 

un moyen pour creer un objet de dispositif utilisant des informations de configuration stockees dans lesdites 

premiere (6) et seconde (10) bases de donnees pour etablir une.communication entre ledit au moins un dispositif 
35 (2) et le systeme de surveillance (8), dans lequel I'objet de dispositif comprend des references a. des informations 

de configuration stockees dans ladite premiere base de donnees (6), les references utilisant des vecteurs ou 

des reseaux ; et 

un moyen pour mettre & jour des informations de configuration, pour ledit au moins un dispositif (2), stockees 
dans la premiere base de donnees (6) avec des informations de configuration stockees dans la seconde base 
40 de donnees (10) pour permettre au systeme de surveillance de s'interfacer avec ledit au moins un dispositif, 

permettant ainsi une souplesse dans la creation d'objets de dispositif. 

14. Appareil selon la revendication 13, dans lequel les informations de configuration comprennent des informations 
liees & : i) un fabricant, ii) un modele, et iii) un identifieur unique dudit au moins un dispositif (2) 

45 

15. Appareil selon la revendication 14, dans lequel les informations de configuration sont seulement utilisees pendant 
Initialisation du systeme de surveillance (8) pour identifier au moins un dispositif (2) qui necessite une surveillance. 

16. Appareil selon la revendication 13, 14 ou 15, comprenant en outre : 

50 

un moyen pour interroger la premiere base de donnees (6) avec au moins un du fabricant, du modeie, et de 
I'identifieur unique dudit au moins un dispositif (2) pour determiner si le systeme de surveillance (8) est configure 
pour s'interfacer avec ledit au moins un dispositif (2). 

55 17. Appareil selon la revendication 13, 14, 15 ou 16, comprenant en outre : 

un moyen pour interroger ledit au moins un dispositif (2) avec des donnees stockees dans la premiere base de 
donnees (6) pour determiner si le systeme de surveillance (8) est configure pour s'interfacer avec ledit au moins 
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un dispositif (2). 

18. Appareil selon Tune quelconque des revendications 13 a 17, dans lequel la premiere base de donnees (6) est une 
base de donnSes de configuration de systeme et comprend : 

5 

des informations de configuration pour permettre une communication entre le systeme de surveillance et ledit 
au moins un dispositif (2) ; et 

des informations d'etat liees audit au moins un dispositif (2), les informations d'etat etent ajoutees apres ('ini- 
tialisation du systeme de surveillance pour surveiller ledit au moins un dispositif (2). 

10 

19. Appareil selon I'une quelconque des revendications 13 a 18, dans lequel ladite seconde base de donnees (10) est 
une base de donnees de support de systeme et comprend des informations concernant divers fabricants et modeles 
de dispositif supportes par le systeme de surveillance (8). 

15 20. Appareil selon I'une quelconque des revendications 1 3 a 1 9, dans lequel I'objet de dispositif permet au systeme de 
surveillance (8) de communiquer avec ledit au moins un dispositif (2) et de determiner des informations de confi- 
guration necessaires a partir dudit au moins un dispositif (2). 

21 . Appareil selon I'une quelconque des revendications 1 3 a 20, dansjequel I'objet de dispositif stockant des references 
20 & des informations de configuration comprend des identifieurs d'objet. 

22. Appareil selon I'une quelconque des revendications 13 a 20, dans lequel ledit au moins un dispositif (2) comprend 
des composants materiels. 

25 23. Appareil selon I'une quelconque des revendications 13 a 22, dans lequel ledit au moins un dispositif (2) comprend 
des composants logiciels. 

24. Programme d'ordinateur comprenant un moyen de code de programme qui, lorsqu'il est execute sur un systeme 
d'ordinateur, donne I'instruction au systeme d'ordinateur de realiser le procede d'une quelconque des revendications 

30 1&12. 

25. Systeme ayant au moins un dispositif (2) raccorde au reseau (4), le systeme comprenant : 

un.dispositif de commande (8).pour surveiller ledit au moins un.disposititraccorde au reseau, ledit dispositif de 

35 commande ayant une logique pour : 

determiner si le dispositif de commande (8) est configure pour s'interfacer avec ledit au moins un dispositif 
raccorde au reseau (2) ; 

obtenir des informations de configuration a partir dudit au moins un dispositif raccorde au reseau (2) si le 
40 dispositif de commande (8) n'est pas configure pour s'interfacer avec ledit au moins un dispositif raccorde 

au reseau (2); 

des premiere (6) et seconde (10) bases de donnees couplees de fagon communicative au dispositif de 
commande (8), ladite seconde base de donnees (10) stockant des informations de configuration pour 
determiner si ledit au moins un dispositif raccorde au reseau (2) est supporte par le dispositif de commande 
45 (8), lesdites premiere (6) et seconde (10) bases de donnees ayant des informations de configuration pour 

creer un objet de dispositif pour etablir une communication entre ledit au moins un dispositif raccorde au 
reseau (2) et le dispositif de commande (8), dans lequel I'objet de dispositif comprend des references a 
des informations de configuration stockees dans la premiere base de donnees, les references utilisant des 
vecteurs ou des r^seaux ; et 

so dans lequel les informations de configuration dans ladite premiere base de donnees (6) sont mises a jour 

avec des informations de configuration stockees dans la seconde base de donnees (10) pour permettre 
au dispositif de commande de s'interfacer avec ledit au moins un dispositif raccorde au reseau (2) , permettant 
ainsi une souplesse dans la creation des objets de dispositif. 

55 

Patentanspruche 

1 . Verfahren zum Aufbauen einer Verbindung zwischen wenigstens einer Vorrichtung und einem Uberwachungssystem 
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(8), wobei die wenigstens eine Vorrichtung (2) und das Oberwachungssystem (8) uber ein Netz (4) kommunikati- 
onsfahig gekoppelt sind, wobei das Oberwachungssystem (8) mit einer ersten Datenbank (6) und mit einer zweiten 
Datenbank (10) kommunikationsfahig gekoppelt ist, wobei das Verfahren die folgenden Schritte umfasst: 

a) Feststellen, ob das Oberwachungssystem (8) so konfiguriert ist, dass es mit der wenigstens einen Vorrichtung 
(2) eine Schnittstelle bildet; 

b) Erhaltenvon Konfigurationsinformationen von der wenigstens einen Vorrichtung (2), falls das Oberwachungs- 
system (8) nicht so konfiguriert ist, dass es mit der wenigstens einen Vorrichtung (2) eine Schnittstelle bildet; 

c) Feststellen, ob die wenigstens eine Vorrichtung (2) durch das Oberwachungssystem (8) unter Verwendung 
von in der zweiten Datenbank (10) gespeicherten Informationen unterstutzt wird; 

d) Erzeugen eines Vorrichtungsobjekts unter Verwendung von in der ersten Datenbank (6) und in der zweiten 
Datenbank (10) gespeicherten Informationen, urn eine Kommunikation zwischen der wenigstens einen Vorrich- 
tung (2) und dem Oberwachungssystem (8) aufzubauen, wobei das Vorrichtungsobjekt Bezugnahmen auf 
Konfigurationsinformationen enthalt, die in der ersten Datenbank (6) gespeichert sind, wobei die Bezugnahmen 
Vektoren oder Matrizen verwenden; und 

e) Aktualisieren von in der ersten Datenbank (2) gespeicherten Konfigurationsinformationen fur die wenigstens 
eine Vorrichtung (2) mit in der zweiten Datenbank (10) gespeicherten Konfigurationsinformationen, damit das 

~ Oberwachungssystem (8) mit der wenigstens einen Vorrichtung (2) eine Schnittstelle bilden kann, wodurch eine 
Flexibility bei der Erzeugung von Vorrichtungsobjekten ermoglicht wird. 

Verfahren nach Anspruch 1 , bei dem der Schritt des Erhaltens von Konfigurationsinformationen von der wenigstens 
einen Vorrichtung (2) das Identifizieren wenigstens eines der folgenden umfasst: i) Hersteller der Vorrichtung (2), 
ii) Modell der Vorrichtung (2) und iii) eindeutige Kennung der wenigstens einen Vorrichtung (2). 

25 3. Verfahren nach Anspruch 2, bei dem die Konfigurationsinformationen nur wahrend der Initialisierung des Oberwa- 
chungssystems verwendet werden, urn festzustellen, ob wenigstens eine Vorrichtung (2) eine Oberwachung erfor- 
dert. 

4. Verfahren nach Anspruch 1 , 2 oder 3, bei dem der Schritt des Feststellens, ob das Oberwachungssystem (8) so 
30 konfiguriert ist, dass es mit der wenigstens einen Vorrichtung (2) eine Schnittstelle bildet, das Abfragen der ersten 

Datenbank (6) mit dem Hersteller und/oder dem Modell und/oder der eindeutigen Kennung der wenigstens einen 
Vorrichtung (2) umfasst. 

5. Verfahren nach Anspruch 1,2,3 oder 4, bei dem der Schritt des Feststellens, ob das Oberwachungssystem (8) so 
35 konfiguriert ist, dass es mit der wenigstens einen Vorrichtung (2) eine Schnittstelle bildet, das Abfragen der wenig- 
stens einen Vorrichtung (2) mit in der ersten Datenbank (6) gespeicherten Daten umfasst. 

6. Verfahren nach Anspruch 5, bei dem die erste Datenbank (6) eine Systemkonfigurationsdatenbank ist und umfasst: 

40 Konfigurationsinformationen, die eine Kommunikation zwischen dem Oberwachungssystem und der wenigstens 

einen Vorrichtung (2) ermoglichen; und 

Statusinformationen, die auf die wenigstens eine Vorrichtung (2) bezogen sind, wobei die Statusinformationen 
nach der Initialisierung des Uberwachungssystems (8) hinzugefugt werden, um die wenigstens eine Vorrichtung 
(2) zu uberwachen. 

45 

7. Verfahren nach einem der vorhergehenden Anspruche, bei dem die zweite Datenbank (10) eine Systemunterstut- 
zungsdatenbank ist und Informationen uber verschiedene Hersteller und Vorrichtungsmodelle, die durch das Ober- 
wachungssystem (8) unterstutzt werden, enthalt. 

50 8. Verfahren nach einem der vorhergehenden Anspruche, bei dem der Schritt des Feststellens, ob die wenigstens 
eine Vorrichtung durch das Oberwachungssystem (8) unterstutzt wird, ferner das Erhalten detaillierter Statusinfor- 
mationen der wenigstens einen uberwachten Vorrichtung (2) umfasst, falls der Hersteller und das Modell der we- 
nigstens einen Vorrichtung (2) durch das Oberwachungssystem (8) unterstutzt werden. 

ss 9. Verfahren nach einem der vorhergehenden Anspruche, bei dem das Vorrichtungsobjekt dem Oberwachungssystem 
(8) ermoglicht, mit der wenigstens einen Vorrichtung (2) zu kommunizieren und Konfigurationsinformationen, die 
von der wenigstens einen Vorrichtung (2) benotigt werden, zu bestimmen. 
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10. Verfahren nach einem der vorhergehenden Anspruche, bei dem das Vorrichtungsobjekt, das Bezugnahmen fur 
Konfigurationsinformationen speichert, Objektkennungen enthalt. 

11. Verfahren nach einem der vorhergehenden Anspruche, bei der die wenigstens eine Vorrichtung (2) Hardware- 
Komponenten enthalt. 

12. Verfahren nach einem der vorhergehenden Anspruche, bei dem die wenigstens eine Vorrichtung (2) Software- 
Komponenten enthalt. 

13. Vorrichtung, die so beschaffen ist, dass sie eine Verbindung mit wenigstens einer Vorrichtung (2) aufbaut, die uber 
ein netzbasiertes System kommunikationsfahig gekoppelt ist, wobei die Vorrichtung umfasst: 

ein Oberwachungssystem (8), das mit dem Netz kommunikationsfahig gekoppelt ist; 
eine erste Datenbank (6) und eine zweite Datenbank (10), die mit dem Oberwachungssystem (8) kommunika- 
tionsfahig gekoppelt sind; 

Mittel, urn festzustellen, ob das Oberwachungssystem so konfiguriert ist, dass es mit der wenigstens einen 

Vorrichtung (2) eine Schnittstelle bildet; 
"Mittel, urn Konfigurationsinformationen von der wenigstens einen Vorrichtung (2) zu erhalten, falls das Ober- 
. wachungssystem (8).nicht so konfiguriert ist, dass es mit der wenigstens einen Vorrichtung eine Schnittstelle 

bildet; 

Mittel, urn festzustellen, ob die wenigstens eine Vorrichtung (2) durch das Oberwachungssystem (8) unterstutzt 
wird, unter Verwendung von in der zweiten Datenbank (10) gespeicherten Konfigurationsinformationen; 
Mittel, urn unter Verwendung von Konfigurationsinformationen, die in der ersten Datenbank (6) und in der 
zweiten Datenbank (10) gespeichert sind, ein Vorrichtungsobjekt zu erzeugen, urn eine Kommunikation zwi- 
schen der wenigstens einen Vorrichtung (2) und dem Oberwachungssystem (8) aufzubauen, wobei das Vor- 
richtungsobjekt Bezugnahmen fur Konfigurationsinformationen, die in der Datenbank (6) gespeichert sind, ent- 
halt, wobei die Bezugnahmen Vektoren Oder Matrizen verwenden; und 

Mittel, urn in der ersten Datenbank (6) gespeicherte Konfgurationsinformationen fur die wenigstens eine Vor- 
richtung (2) mit in der zweiten Datenbank (10) gespeicherten Konfigurationsinformationen zu aktualisieren, 
damit das Oberwachungssystem mit der wenigstens einen Vorrichtung eine Schnittstelle bilden kann, wodurch 
eine Flexibility bei der Erzeugung von Vorrichtungsobjekten ermoglicht wird. 

14. Vorrichtung nach Anspruch 13, bei der die Konfigurationsinformationen Informationen enthalten, die bezogen sind 
auf: i) Hersteller, ii) Modell und iii) eindeutige Kennung der wenigstens einen Vorrichtung (2). 

15. Vorrichtung nach Anspruch 14, bei der die Konfigurationsinformationen nur wahrend der Initialisierung des Ober- 
wachungssystems (8) verwendet werden, urn wenigstens eine Vorrichtung (2), die eine Oberwachung erfordert, zu 
identifizieren. 

16. Vorrichtung nach Anspruch 13, 14 oder 15, die ferner umfasst: 

Mittel, urn die erste Datenbank (6) mit dem Hersteller und/oder dem Modell und/oder der eindeutigen Kennung 
der wenigstens einen Vorrichtung (2) abzufragen, urn festzustellen, ob das Oberwachungssystem (8) so kon- 
figuriert ist, dass es mit der wenigstens einen Vorrichtung (2) eine Schnittstelle bildet. 

17. Vorrichtung nach Anspruch 13, 14, 15 Oder 16, die ferner umfasst: 

Mittel, urn die wenigstens eine Vorrichtung (2) mit in der ersten Datenbank (6) gespeicherten Daten abzufragen, 
urn festzustellen, ob das Oberwachungssystem (8) so konfiguriert ist, dass es mit der wenigstens einen Vor- 
richtung (2) eine Schnittstelle bildet. 

18. Vorrichtung nach einem der Anspruche 13 bis 17, bei der die erste Datenbank (6) eine Systemkonfigurationsda- 
tenbank ist und umfasst: 

Konfigurationsinformationen, die eine Kommunikation zwischen dem Oberwachungssystem und der wenigstens 
einen Vorrichtung (2) ermoglichen; und 

Statusinformationen, die auf die wenigstens eine Vorrichtung (2) bezogen sind, wobei die Statusinformationen 
nach der Initialisierung des Oberwachungssystems hinzugefugt werden, urn die wenigstens eine Vorrichtung 
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(2) zu uberwachen. 

19. Vorrichtung nach einem der Anspruche 13 bis 18, bei der die zweite Datenbank (10) eine Systemunterstutzungs- 
datenbank ist und Informationen uber verschiedene Hersteller und Vorrichtungsmodelle, die durch das Uberwa- 
chungssystem (8) unterstutzt werden, enthalt. 

20. Vorrichtung nach einem der Anspriiche 13 bis 19, bei der das Vorrichtungsobjekt dem Uberwachungssystem (8) 
ermoglicht, mit der wenigstens einen Vorrichtung (2) zu kommunizieren und Konfigurationsinformationen zu be- 
stimmen, die von der wenigstens einen Vorrichtung (2) benotigt werden. 

21. Vorrichtung nach einem der Anspriiche 13 bis 20, bei der das Vorrichtungsobjekt, das Bezugnahmen fur Konfigu- 
rationsinformationen speichert, Objektkennungen enthalt. 

22. Vorrichtung nach einem der Anspriiche 13 bis 20, bei der die wenigstens eine Vorrichtung (2) Hardware-Kompo- 
nenten enthalt. 

23. Vorrichtung nach einem der Anspruche 1 3 bis 22, bei der die wenigstens eine Vorrichtung (2) Software- Komponenten 
enthalt. 

24. Computerprogramm, das Programmcodemittel enthalt, die, wenn sie auf einem Computersystem a usgefiihrt werden, 
das Computersystem anweisen, das Verfahren nach einem der Anspruche 1 bis 12 auszufiihren. 

25. System, das wenigstens eine mit einem Netz (4) verbundene Vorrichtung (2) besitzt, wobei das System umfasst: 

eine Steuereinheit (8), urn die wenigstens eine mit dem Netz verbundene Vorrichtung zu uberwachen, wobei 
die Steuereinheit eine Logik aufweist, urn: 

festzustellen, ob die Steuereinheit (8) so konfiguriert ist, dass sie mit der wenigstens einen uber das Netz 
verbundenen Vorrichtung (2) eine Schnittstelle bildet; und um 

Konfigurationsinformationen von der wenigstens einen uber das Netz verbundenen Vorrichtung (2) zu 
erhalten, falls die Steuereinheit (8) nicht so konfiguriert ist, dass sie mit der wenigstens einen mit dem Netz 
verbundenen Vorrichtung (2) eine Schnittstelle bildet; 

eine erste Datenbank (6) und eine zweite Datenbank (1 0), die mit der Steuereinheit (8) kommunikationsfahig 
gekoppelt sind, wobei die zweite Datenbank (10) Konfigurationsinformationen speichert, um festzustellen, 
ob die wenigstens eine mit dem Netz verbundene Vorrichtung (2) durch die Steuereinheit (8) unterstutzt 
wird, wobei die erste Datenbank (6) und die zweite Datenbank (10) Konfigurationsinformationen besitzen, 
um ein Vorrichtungsobjekt zu erzeugen um eine Kommunikation zwischen der wenigstens einen mit dem 
Netz verbundenen Vorrichtung (2) und der Steuereinheit (8) aufzubauen, wobei das Vorrichtungsobjekt 
Bezugnahmen fur in der ersten Datenbank gespeicherte Konfigurationsinformationen enthalt, wobei die 
Bezugnahmen Vektoren oder Matrizen verwenden; und 

wobei die Konfigurationsinformationen in der ersten Datenbank (6) mit in der zweiten Datenbank (10) gespei- 
cherten Konfigurationsinformationen aktualisiert werden, damit die Steuereinheit mit der wenigstens einen mit 
dem Netz verbundenen Vorrichtung (2) eine Schnittstelle bilden kann, wodurch eine Flexibi litat bei der Erzeugung 
von Vorrichtungsobjekten ermoglicht wird. 
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